126

A. Banerjee et al.

At this point, it should be clear how the concept of SSI, DID and Wallets gives an

identity to an entity in the network. This identity is not federated and hence cannot be

taken away when a third party stops functioning. Thus, it also removes the risk of data

leakage on part of the third party. The aforementioned two points are considered to be

two gaping disadvantages of Federated Identity (a common example would include

signing up or logging into a site using one’s Gmail, Facebook, or GitHub ID).

Italsoremovestheriskofcorrelationofidentitiesofanentitytoagreatextentsince

these identities are “pairwise” unique. Consider a case where a subject repetitively

uses his or her Facebook to log into multiple sites. These sites may or may not share

data among themselves. But if two or more of these sites get breached and the data of

the user is stolen, it would be easy to correlate the data from multiple sites and link

it to a person since the data contain common elements from the Facebook Login.

Nodes (Validators, Observers)

The important feature in Hyperledger Indy is that it is public yet permissioned ledger.

The main architecture of it comprises Validators and Observers. These are regarded

as Nodes in the network. A node can be anything ranging from a server, to a virtual

machine or a docker container running in a Kubernetes Pod. Validator Pool handles

Writes and Reads. These nodes participate in consensus. On the other hand, Observer

Pool handles Reads. Observers keep their states synchronized with the Validators.

Figure 7 illustrates the nodes acting in the network.

Ledger

Ledger is an ordered log of transactions stored in a DLT network. This is basically

the core of the whole “Blockchain” or “Distributed Ledger” ideology. Ledgers are

basically databases that are replicated across nodes in a network. Indy has different

types of ledgers each with a separate transaction log and merkle tree. Figure 8 shows

the ledgers available in Hyperledger Indy.

Redundant Byzantine Fault Tolerance and Plenum

Redundant Byzantine Fault Tolerance or RBFT is a variant developed from Practical

Byzantine Fault Tolerance consensus mechanism. It works on the concept of “multi-

phase commit” for reaching consensus on a specific piece of information (hence the

“Redundant”). Plenum is Hyperledger Indy’s implementation of RBFT and works

at the core of the Indy Nodes to provide secure consensus. Because of it, Indy

Nodes’ Network can tolerate a 33% failure rate (including malicious actors and

malfunctioning actors). Figure 9 gives the consensus, Plenum.